API v2 Feedback

#1

We have a small team of developers who use PD via the e-mail integrations. So far we’ve been sending HTML messages but we’d like to move off that.

We’ve started experimenting with V2 and I must say it’s disappointing so far:

  1. The optional payload keys (group, component, class) are not rendered on the website. This means I have to dump them into payload.custom_details to see them.
  2. The ordering of key/value pairs inside payload.custom_details is apparently not respected. It is presented on the website as a big ugly jumble of information.
  3. The formatting of payload.custom_details is a bit odd, it adds all sorts of random unnecessary whitespace and linebreaks (use CSS if you need this to look a certain way!).

Would be great to see these issues addressed.

#2

HI Ollie,

Thank you for your feedback regarding our API, we always are happy to hear how we can improve things! To update you, I have talked internally with our team here and I went ahead and filed a feature request on your behalf for items you mentioned.

Let me know if you have any other questions.

Thanks!
John

#3

Hi, do you guys have any updates or thoughts on my feedback? Hopefully it hasnt got lost in a JIRA black hole! We would love to start using this feature to deliver alerts but the relative lack of UI support for it is holding us back.

#4

Hello Oliver,

Many thanks for reaching out again.

As mentioned in our last post, your feedback has been raised with the Product Team as a Feature Request. Whilst we don’t have a timeline as to when this will be available, I would suggest you keep abreast of such release and more by signing on to Pulse. New features are detailed there once they have been developed.

I hope this helps.

#5

Hello Oliver,

Just one more thing I’d like to point out, which may help address your first original concern: the display of the PD-CEF fields group, component and class. These can be displayed in the Alerts view table by clicking on the Customize Columns button on the far right and checking the corresponding boxes to enable them. They are not enabled by default, and so, are not displayed.

However, it is advantageous to use these PD-CEF fields as opposed to custom details fields because, once they’re enabled in the alerts table, one can sort and filter on them to pinpoint specific event data that was sent to PagerDuty through PD-CEF-enabled integrations (i.e. v2 Events API) that populate them.

The following payload produces the following alert (see screenshot):

{
    "routing_key": "[redacted]",
    "event_action": "trigger",
    "dedup_key": "abc123",
    "payload": {
        "summary": "Something happened",
        "source": "somewhere",
        "severity": "critical",
        "custom_details": {"field name": "field value"},
        "class": "class::name",
        "group": "groupname",
        "component": "componentname"
    },
    "images": [{
        "src": "https://http.cat/504.jpg"
    }]
}

test-alert

2 Likes
#6

@Inactive-Member-99077006 @demitri
Hello,

I am trying to experiment with Event API v2. I want to register an alert which has PD-CEF fields values.
Where do I set these values in order to register them in new alerts?

I tried sending dummy data using this link : https://v2.developer.pagerduty.com/docs/send-an-event-events-api-v2
Even though it shows “202 Accepted”, there is no incident that gets registered at the service with routing_key that I have mentioned.

I also tried to manually create and incident and used it’s incident_key (as dedup_key) to resolve the incident using the same link. Again, the status is shown as “Accepted”, but the actual incident doesn’t get resolved.

Waiting for your explanation.

Thank you.
Arpan

#7

@Arpanbhagat5

The PD-CEF fields are exactly as given in our API docs article on sending an event. Payload, source, severity, class… these are all PD-CEF fields and the v2 Events API should allow you to set them directly in the alert.

If you can send one of us through a private channel (i.e. in a direct message) the URL to view the integration’s settings in PagerDuty (NOT the “Integration URL” if any) then that would allow us to further examine why it did not trigger or resolve.

#8

@demitri
I was able to resolve it. There were multiple misses on my side, which I carefully checked later.

But i am not sure how to use them with full effect. Can you share the use cases where such metadata can be used?
Thank you. :slight_smile:

#9

Hi @Arpanbhagat5

Each PD-CEF field can be used in a filter in the Alerts index view and for event rules, so it effectively represents another way that one can classify alert data for automatic triage (i.e. auto-suppression if it’s not actionable) or when scrutinizing it post-hoc, i.e. doing research for a postmortem.

Furthermore, in the view of the alerts/incidents themselves (during incident response), PD-CEF fields are more prominently displayed. The idea behind them is to provide a uniform set of features for actionable data. The various diverse features of event data from all different products are translated to these fields in our event transformer (for integrations that use them, i.e. AWS CloudWatch). The v2 Events API just lets you set them directly.

There is more about PD-CEF written in our article on the topic:

1 Like